Data security is a serious concern of computer users and owners of intellectual property. It is increasingly common to use measures such as encryption to secure data files, to protect data from loss or unauthorized activity.
Computer systems typically include one or more local or networked data storage devices. A typical application program executing on such a computer system, accesses such data storage devices by calling standard file system services provided by an operating system, such as services for creating, reading, and writing files on the data storage devices.
A device driver is a set of computer-implemented instructions that implements the device-specific aspects of generic input/output operations. In typical operating systems, software applications such as device drivers run in either “kernel mode” or “user mode.” A virtual device driver is a type of device driver that has direct access to an operating system kernel, such as by running in kernel mode. “Kernel mode” is a highly privileged memory access mode of the processor. “User mode” is a less privileged memory access mode of the processor. The memory access mode is a part of the hardware state of the processor. The kernel mode privilege level is also known as “Ring 0,” and the user mode privilege level is also known as “Ring 3.” Kernel mode access allows the virtual device driver to interact with system and hardware resources at a very low level.
In conventional operating systems, device drivers may be represented as layered on top of one another. The layered architecture is also sometimes referred to as a stack or a calling chain. It is the lowest-level device driver that typically controls a hardware device. If there is only a single device driver above the hardware device, the driver is called a monolithic driver.
However, a plurality of drivers may be placed above the lowest-level driver. Input and output requests (“I/O requests”) to the hardware device or devices controlled by a lowest-level driver are handled first by the highest-level driver, then seriatim by any lower-level intermediate drivers, and finally by the lowest-level driver.
A file system driver is generally a highest-level driver, layered above a device driver for a data storage device such as a hard disk drive. The file system driver implements high-level aspects of I/O requests directed to the file system, such as requests to create, open, extend, and delete files and directories. A plurality of file system drivers may exist in a single computer, and file system drivers may be specific to different types of file systems, such as the FAT and NTFS file systems.
It is known in the art to monitor file I/O requests in operating systems having an installable file system manager and layered device drivers, such as the Windows 95®, Windows 98®, and Windows Me® operating systems available from Microsoft Corporation of Redmond, Wash., and collectively referred to herein as “Windows 9x”. In Windows 9x operating systems, file system monitoring may be accomplished by registering a file system applications programing interface hook with the installable file system manager. Windows 9xprovides a function called IFSMGR_InstallFileSystemApiHook which is designed to be used for monitoring I/O requests to a file system. This service allows virtual device drivers to monitor all file system activity by hooking into the file system calls. By means of a call during system initialization to IFSMGR_InstallFileSystemApiHook, a virtual device driver may insert itself onto the stack of all file system requests.
A somewhat different approach has been used to monitor file systems on object-oriented operating systems, such as the Windows NT® operating system and successor operating systems such as Windows 2000®, available from Microsoft Corporation of Redmond, Wash., and collectively referred to herein as “Windows NT.” In Windows NT, I/O requests are described by data structures known as I/O Request Packets (“IRPs”), which are used for communication between software applications and drivers. All IRPs to hardware devices are handled by device drivers operating in kernel mode. High-level, intermediate, and low-level drivers exchange IRPs to complete a given I/O request. The lowest-level driver calls an NT layer known as the Hardware Access Layer (HAL) to gain direct control of the hardware. It is known on a Windows NT system to implement a file system monitor as a device driver object that creates filter device objects and attaches those objects to target file system device objects, so that the file system monitor will see all IRPs directed to the monitored data storage devices.
It is known to store secured files, such as encrypted files, alongside unsecured files in the same file system. The encrypted file appears in the file directory like any other file, with relevant file attributes such as name and size. However, the data contained in the file is unintelligible to user applications until decrypted. Furthermore, the encryption process is likely to result in the size of the file becoming larger or smaller than the original unencrypted data. In such a case, a request to the file system to determine the file size would not reliably return the actual size of the original data. From the user's point of view, this type of data security lacks the desirable feature of transparency.
It is also known to store secured files in a special physical or virtual location apart from the ordinary file system. Such locations may include remote networked devices, encrypted or password-protected file systems, or other virtual secured file systems. This type of data security prevents the user from freely intermingling secured and unsecured files in a single file directory, even though the files may be logically related to one another. Although a user may set up, in the unsecured directory, symbolic links or shortcuts to secured files in another location, such an exercise for authorized persons adds an undesirable layer of obfuscation and effort to the process of conveniently accessing secured data